Add barrel export and exports map to packages/components#6130
Add barrel export and exports map to packages/components#6130michaell-workday merged 11 commits intomainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces subpath exports for the flowise-components package, establishing a stable entry point for node-level utilities and adding a dependency override for es-iterator-helpers. Review feedback highlights potential issues with the wildcard export mapping that could lead to incorrect file resolution when extensions are used, and suggests narrowing the broad catch-all export to avoid exposing internal package files.
michaell-workday
requested review from
VaidikFlow,
harshit-flowise,
henry-heng-wd,
jocelynlin-wd and
mmattu-wd
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces subpath exports for the flowise-components package, adds a new entry point for node-level utilities, and includes a dependency override. Feedback was provided regarding the exports configuration in package.json, specifically that the catch-all mapping could break backward compatibility for existing deep imports and access to root files like package.json.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a new barrel file for node-level utilities and configures package exports in packages/components/package.json to expose them. It also adds a dependency override for es-iterator-helpers in the root package.json. Feedback was provided to refine the exports configuration, specifically suggesting a mapping for node subpaths to ensure they resolve correctly to the dist directory and avoid potential module resolution errors.
muratkaratekeli
left a comment
muratkaratekeli
left a comment
There was a problem hiding this comment.
One thing on the exports map: the "./": "./" catch-all exposes the entire package directory as importable paths. I see you went back and forth on this in the commits, narrowed to dist only, then went back to export all. Could we tighten this to just the two explicit entries (. and ./nodes) without the wildcard? Keeps the public API surface small and makes it easier to refactor internals later without worrying about breaking consumers.
changes look good |
4 participants
Summary
exportsfield topackages/components/package.jsonto declare the official public API surface offlowise-componentspackages/components/nodes/index.tsas a stable barrel entry point for MCP node utilitieses-iterator-helpers@1.0.15in pnpm overrides to resolve a transitive dependency conflict with pre-commit hooksBackground
flowise-componentshad noexportsfield, meaning Node.js resolved imports by directly walking the filesystem. This worked forflowise-components(the main entry) but meantflowise-components/nodeshad no defined entry —nodes/index.tscompiles todist/nodes/index.js, notnodes/index.js, so the import failed at runtime withMODULE_NOT_FOUND.Changes
packages/components/nodes/index.tsNew barrel file that re-exports MCP toolkit utilities (
MCPToolkit,MCPTool, validation helpers) fromnodes/tools/MCP/core. Consumers should import fromflowise-components/nodesrather than deep paths, insulating them from internal refactors.packages/components/package.json—exportsfieldTwo explicit entry points:
All other subpath imports (deep paths, dist/-prefixed paths) are intentionally not exposed.
package.json (root)
Added "es-iterator-helpers": "1.0.15" to pnpm.overrides to resolve a transitive version conflict surfaced in pre-commit hooks.
Breaking change
Adding an exports field opts out of CJS automatic extension guessing and restricts the importable subpaths to those explicitly listed. Any consumer importing subpaths other than flowise-components or flowise-components/nodes will receive ERR_PACKAGE_PATH_NOT_EXPORTED. The fix is to migrate to one of the two supported entry points.